Examples of 3GPP (3rd Generation Partnership Project) LTE (Long Term Evolution) protocol stacks for control and user planes are illustrated in FIG. 1. One or more of these layers are implemented in nodes in LTE. For example, in a typical UE (user equipment), all layers of both control and user plane protocol stacks are implemented. In a typical eNB (or more generically a network node), all user plane protocol layers and all control plane protocol layers except for the NAS layer are implemented.
According to 3GPP, the new LTE Rel-10 UE categories have recently been defined so that data rates up to 3 and 1.5 Gbps can be reached in the downlink and uplink, respectively. This is enabled by increasing the number of layers for spatial multiplexing and the number of carriers that can be configured for the single UE. With these enhancements, the maximum Transport Block (TB) size is increased to 299852 bits (37482 octets) at the physical (PHY) layer, and the number of transport blocks that can be sent in a single subframe is increased to 10.
However, the U-plane protocol formats defined for LTE Rel-8/9 do not fully support transmission at the high data rates offered by the improved physical layer. This applies to all three sublayers of the L2 (link) layer, i.e., the MAC (Media Access Control) layer, the RLC (Radio Link Control) layer and the PDCP (Packet Data Convergence Protocol) layer.
A size of a MAC SDU (Service Data Unit) contained in a MAC PDU (Protocol Data Unit) can be signalled in a length field (L) of a MAC subheader except when a MAC SDU is included last in the MAC PDU (i.e., not followed by any other data, control or padding) for which no L field is included. Examples of existing MAC subheader structures are illustrated in FIGS. 2A, 2B and 2C
The MAC subheader includes of two reserved bits (R), a 1-bit extension field (E), a 5-bit logical channel field (LCID). The E field is used to indicate whether more fields are present in the MAC subheader. When the E field is not set, then the MAC subheader includes fields R/R/E/LCID as illustrated in FIG. 2C. The last subheader in the MAC PDU and subheaders for fixed size MAC control elements conform to this structure.
For other MAC SDUs, i.e., when the E field is set, the corresponding MAC subheader also includes a 1-bit format field (F) and a 7- and 15-bit L field as illustrated in FIGS. 2A and 2B, respectively. That is, when the E field is set, the MAC subheader includes R/R/E/LCID/F/L fields. The F field indicates the size of the L field. When the F field is set, the L field size is 15 bits as illustrated FIG. 2B, and when the F field is not set, the L field size is 7 bits as illustrated in FIG. 2A.
As illustrated in FIG. 3, a MAC PDU includes a MAC header, zero or more MAC control elements, zero or more MAC SDUs, and an optional padding. The MAC PDU header includes one or more MAC subheaders in which each MAC subheader corresponds to one of a MAC SDU, control element, or padding. The entire MAC PDU—header, control elements, SDUs and padding—is transported in a transport block of the physical (L1) layer.
Referring back to FIGS. 2A-2C, note that the L field is at most 15 bits long. Thus, the maximum supported size of a MAC SDU including the L field is 32767 octets. The L field is included in all MAC PDUs having more than one MAC subheaders. For example, if a MAC PDU includes more than 2 octets of padding in addition to data, the size of the MAC SDU for the data needs to be indicated with the L field. According to the Rel-8/9 specification, each L1 code-word contains exactly one MAC PDU (transport block). Taking the L field limitations into account, the MAC layer cannot fill the MAC PDU with one MAC SDU for the data. On the other hand, having multiple MAC SDUs for new data per logical channel and per transport block is not allowed. With these limitations, a consequence is that the MAC layer cannot make use of the large transport formats offered by the physical layer.
In certain systems supporting RLC, each of the RLC SDUs in an RLC PDU is associated with an 11-bit length indicator field “LI”. This limits the possibility of concatenation when RLC SDUs or a remainder of a segmented RLC SDU exceeds 2047 octets. The last RLC SDU does not have the LI field, and it is therefore only limited by the maximum size of the RLC PDU. If concatenation of RLC SDUs is not possible, the RLC layer may generate multiple RLC PDUs instead. Unfortunately, this consumes more RLC SNs (sequence numbers).
This can be problematic since the RLC SN is a 10-bit field (1024 values) which limits the usable window size to 511 RLC PDUs. That is, the RLC transmitter can generate and transmit up to 511 RLC PDUs before receiving an accumulative status message. As will be discussed later, this becomes particularly limiting when concatenation of RLC SDUs is not possible. Further, the RLC PDU size is limited by the RLC SO (segmentation offset) fields—SOstart and SOend—which are 15 bits each. Thus the size of an RLC PDU is limited to the size of the maximum size of a MAC SDU with the L field.
PDCP supports PDCP SDUs of up to 8188 octets in size, which results in a maximum PDCP Data PDU size of 8190 octets including the header. Note that the PDCP SDU size can only be upper-bounded, but it is hardly possible to enforce a lower limit. Typical PDCP SDU (e.g., IP packet) sizes are in the order of 1500 octets. It should further be noted that PDCP PDUs exceeding 2047 octets require special handling at the RLC layer as indicated above.